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memory . 

A  major  motivation  for  VIP  is  collecting  parametric  values  for,  and  providing 
validation  of,  system  models  of  the  VAX*  In  the  past  few  years,  sophisticated 
and  powerful  modeling  techniques  have  been  developed.  A  major  problem  in  the 
application  of  these  techniques  is  that  actual  systems  do  not  monitor  those 
input  parameters  that  are  necessary  for  the  application  of  the  modeling 
techniques.  Furthermore,  these  modeling  techniques  typically  provide  perform¬ 
ance  measures  v/hich  are  more  extensive  than  are  usually  measured.  Validation, 
as  well  as  the  construction,  of  accurate  models  is  thus  a  difficult  problem. 


During  the  design  process  of  VIP,  several  existing  software  monitors  were 
examined  in  detail.  VIP  includes,  extends,  and  deletes  several  of  the  ideas 
from  these  existing  monitors.  The  specific  monitors  examined  include: 
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Design  of  Che  VAX  Instrumentation  Package  (VIP) 
L.W.  Dowdy,  W.S.  Freeze,  B.G.'Labaw,  and  J.X.  Reed 


1 .  In  troduc  cion 

This  report  describes  the  design  of  die  VAX  Instrumentation 
Package  (VIP).  The  targe  t  mach ine  initially  is  the  VAX  11/780  running 
under  the  Unix  operating  system  at  the  Computer  Science  Department  of 
the  University  of  Maryland. 

VIP  is  a  software  monitor  of  VAX  performance.  1 1  Is  designed  as 
an  aid  for  system  monitoring,  system  tuning,  and  system  modeling.  For 
example,  VIP  monitors  the  request  rate  of  system  files.  If  the  request 
rate  of  a  particular  file  becomes  high,  the  sys  tein  may  be  '‘tuned'*  by 
making  the  file  resident  in  main  memory.  Specific  parameters  of  the 
file  (e.g.,  the  average  number  of  words  transferred  per  file  request) 
may  be  used  in  a  queuing  network  model  of  the  sys  tern  to  predict  the 
performance  .impact  of  making  the  file  resident  In  main  memory. 

A  major  motivation  for  VIP  is  collec  ting  parametric  values  for, 
and  providing  validation  of,  system  models  of  the  VAX.  In  the  past  few 
years,  sophisticated  and  powerful  modeling  techniques  have  been 
developed  [1].  A  major  problem  in  the  application  of  these  techniques 
is  that  actual  sys  terns  do  not  monitor  those  input  parameters  that  are 
necessary  for  the  application  of  the  modeling  techniques.  Fur  the  nr.  o  re, 
these  modeling  techniques  typically  provide  performance  measures  which 
are  more  extensive  than  are  usually  measured.  Validation,  as  well  as 
the  construction,  of  accurate  models  .is  thus  a  difficult  p rob lan. 

During  the  design  process  of  VIP,  several  existing  sor  tware 
monitors  were  examined  in  detail.  VIP  includes,  extends,  and  deletes 
several  of  the  ideas  from  these  existing  monitors.  The  specific 
monitors  examined  include: 

Univac  SIP  [2] 

VAX  VMS  Display  Utility  [3] 

Burroughs  SPARK  [4] 

IBM  RMF/SMF  [5] 

Tandem  XRAY  [6]  A1R  F0RC£  OFFICE  OF  SCIENTIFIC  RESEARCH  (ATSC) 

NOTICE  OF  TRANSMITTAL  TO  DDC 
This  technical  rvij.-rt.  :.?z  been  reviewed  and  is 
approved  ."or  public  rt  lease  I  A'#  AFR  190-12  (7b), 
Distribution  io  unlimited. 

A.  D.  BLOSE 

Technical  In/ornetion  Officer 


Figure  1:  VIP  Structure 

A  user  initiates  VIP.  The  user  can  specify  various  options. 
These  options  include:  a)  the  specific  performance  information  desired, 
b)  the  specific  process  type(s)  (e.g.,  batch,  system  overhead,  Fortran) 
that  the  user  desires  to  monitor,  and  c)  timing  information  describing 
the  resolution  and  the  length  of  the  monitoring  session*  For  example,  a 
user  may  request  cpu  and  disk  utilizations  (i.e.,  option  a),  for  small 
batch  jobs  (i.e.,  option  b)  ,  to  be  reported  over  a  30  minute  period  in  5 
minute  intervals  (i.e.,  option  c).  VIP  monitors  the  requested  activity 
and,  according  to  user  specified  timing  resolutions,  logs  the 
information  on  secondary  storage.  Concurrently,  or  at  some  later  time, 
the  logged  information  is  used  by  a  data  reduction  program,  DRP,  which 
analyzes  the  data  and  produces  reports  for  the  user.  Upon  receiving 
initial  reports,  the  user  can  dynamically  alter  the  parameters  used  by 
VIP.  Since  the  timing  input  parameters  and/or  the  monitored  events  can 
be  changed,  the  overhead  of  running  VIP  on  the  system  is  variable. 

Section  2  of  this  report  specifies  the  data  structures  used  by  VIP 
in  recording  the  measurement  Information.  Section  3  gives  the  specific 


Lk 


measured  entities 


2.  Da  ta  S  true  tures 
2 .  i  Record  Types 

To  record  information,  VIP  accesses  one  of  four  types  of 
structures.  The  data  structures  associated  with  a  measurable 
depend  on  its  nature  and  the  desired  level  of  information 
acquired. 


The  four  types  of  data  structures  are  (see  Figure  2):  . 


—  0-Dimens ion-Gric 


1 -Dimension-Grid 


2-Dinension-Gri a 


.00 


Figure  2:  Data  Structure  Types 


A .  0 -D inens  io n-G r  id :  A  0-d in e ns  io n~g r  id  rec ord  is  a 


da  ta 
en  ti  ty 
to  be 


a  Ingle 


coun  ter. 


It  holds  a  count  of  the  number  or  occur  eric  ss  of  an 


w 
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event  (e.g.,  number  of  page  faults). 


B.  1-D  .linens  io  n-Gr  id :  A  1-d  imens  ion-gr  Id  record  is  an  array  of 
single  counters.  The  particular  counter  into  wh 'ch  an  event  is 
recorded  depends  upon  the  specific  measured  quantity.  For 
example,  consider  the  number  of  words  transferred  per  1/0 
request  to  a  disk.  The  number  of  I/O  requests  transferring, 
say  1  to  100  words  might  be  recorded  in  1-d  imens  ion-gr  id  [  i  ]  ; 
the  number  of  I/O  requests  transferring  101  to  200  words  might 
be  recorded  in  1-d  .imens ion-gr  id  [  2 ]  ;  and  so  on.  In  this  way  the 
distribution  of  the  event  is  recorded.  Device  service  time 
distributions  and  queue  length  distributions  can  be  obtained 
using  this  data  structure.  The  number  of  counters  and  the 
ranges  associated  with  each  counter  are  user  definable. 


C.  2-D  imens  ion-Gr  id  :  A  2-d  imens  ion-gr  id  record  is  an  extension 
of  the  1-dimension-grid  record.  The  user  can  specify  the 
meaning  of  each  d. imens  ion*  s  range.  For  example,  suppose  load 
dependent  service  time  distributions  are  desired  of  a  disk 
channel.  That  is,  the  average  time  it  takes  to  satisfy  a  disk 
request  (  .i.  e.  ,  service  time)  depends  upon  the  number  of 
requests  in  the  disk  channel  queue.  This  dependency  may  be 
measured.  When  the  queue  lias  more  than  l  request  present,  the 
average  service  time  per  request  may  be  lower  since  seek 
activity  on  different  disk  units  may  overLap.  The  user  may 
specify  the  first  dimension  range  to  be  associated  with  the 
channel  queue  length  and  the  second  dimension  range  to  be 
associated  with  the  specific  measured  quantity. 

2-d  .imens  ion-gr  id  [  1 , 1  ]  might  record  the  number  of  service 
requests  which  require  0  to  5  msec  of  service  when  1  to  3 
requests  were  in  the  queue;  2-d  .imens  ion-gr  .id  [  1 , 2  ]  might  record 
the  number  of  service  requests  which  require  5  to  10  msec  of 


service  when  1  to  3  recites 


were  in  the  queue; 


2-d  im. e n s  io  n-g r  id  [2,11  m  ig h  t  r ec o rd  th e  nun k or  ■; f  service 
requests  which  require  0  to  5  mse*'  of  service  when  4  to  o 
requests  were  in  the  queue;  2-d  imens  ion-gr  id  ,r2  ,  Z  J  might  record 


i 
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the  number  of  service  requests 
service  when  4  to  6  requests  were 


which  require 
in  the  queue; 


5  to  10  msec  of 
and  so  on  (see 


Figure  3)*  In  this  way  the  relative  dependence  of  one 
measurable  quantity  parameter  of  an  event  to  ar.o  ther  measurable 
quantity  parameter  is  obtained* 


D.  Log  -  A  log  record  is  used  when  none  of  the  other  data 
structures  is  appropriate  to  record  the  occurence  of  an  event* 
This  is  the  case  when  the  number  of  parameters  measured  at  the 
time  of  an  event  is  too  great  to  be  recorded  in  the  other  data 
structures.  A  log  record  is  identified  with  a  single 
occurrence  of  an  event.  Specific  errors  in  the  system  may  be 
recorded  in  this  way. 


channel 

queue 

length 


channel  service  time  (msec) 


0_-5 _ 5  - 10 

i 


1-3 


4-6 


Figure  3:  2-Dimension-Grid  Example 


2.2  Special  Job  Class  Monitoring 

A  value  of  I  or  0,  respectively,  is  assigned  to  a  process  to 
indicate  whether  or  not  the  process  is  singled  out  for  special 
monitoring.  VIP  records  the  measurement  according  to  this  process  type. 
For  example,  the  count  of  the  number  of  disk  operations  might  ne  broken 
into  two  parts:  the  first  corresponding  to  processes  associated  with 
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student  jobs  and  the  second  to  all  other  processes.  Processes  which 
might  be  singled  out  for  special  monitoring  include:  batch  job 
processes,  processes  associated  with  jobs  having  a  certain  account 
number  range,  processes  using  a  certain  piece  of  sor  t.;are.  User 
selection  of  singled  out  processes  may  be  done  dynamically. 


2. 3  Record  Descrip  tions 

2.3.  1  O-Dimension-Gr  id 

A  0~d ime ns io n~g rid  record  contains  the  number  of  tirne^  an  event 
occurred  and  information  about  the  event  itself. 

Forma  t: 

Type 

0-d  omens  ion-gr  id  =  record 


id  number 

:  in  teger; 

leng  th 

: in teger; 

log  time 

:  in  teg  er ; 

Q-gr  id 

: array [0. , 1 ] 

of 

in  teger; 

cum  to  t 

: array [0. .  i  ] 

of 

in  teger; 

s  tar  t  time 

: array [ 0.  .  1  ] 

of 

in  teg  e  r ; 

end; 

Ex  pi  ana  tion: 

id  number  -  Event  identifier, 
length  -  The  record  length  in  words. 

log  time  -  The  time  the  record  was  last  logged  to  secondary  storage 
and  reinitialized. 

Q-grid  -  0-grid[ij  holds  the  number  of  times  the  event  occurred  by 
processes  with  type  1  for  1  =  0  or  1. 


cum  Cot  -  cum  to  t[  i]  holds  the  cumulative  total  of  the  measurement 
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values  (i.e.,  the  ac  ami  quantities  measured  by  VIP) 
associated  with  processes  of  type  i  for  i  =  0  or  i.  For 
example,  to  determine  the  :  of  tine  that  a  fhunnul  is 

idle  while  a  connected  device  is  busy  (e.g.,  seeking), 
cum  to  t[  I]  would  hold  this  cumulative  tune  for  type  i 
processes,  while  cumtot[G]  holds  the  same  for  all  other 
processes.  In  contrast,  0-grid[i)  would  contain  the 
number  of  times  that  the  channel  is  idle  while  the  device 
is  busy  for  type  i  processes. 

s  tart  time  -  starttime[i]  holds  the  last  time  VIP  accessed  the 
record  by  a  type  i  process. 


Ex  am  pi  e: 

A  0-d imens io n~gr id  record  might  be  used  to  record  disk  busy  times. 
VIP  accesses  the  record  whenever  a  disk  request  is  initiated  or 
terminated.  For  in  initiation,  the  start  time  is  s  imply  recorded.  For  a 
termination,  the  recorded  starttime  is  subtracted  from  the  current  tine 
to  give  the  busy  time.  This  number  is  then  added  to  cum  tot,  and  0-grid 
is  incremented  by  one.  The  average  busy  time  per  request  can  later  ne 
calculated  by  the  DR?  by  dividing  cum  tot  by  0-grid. 


2.3.2  i-Dimension-Crid 

A  1-d  imens  ion-gr  id  record  is  an  extension  of  a  O-dimension-grid 
record  used  for  capturing  information  needed  to  determine  distributions. 
The  1-d imens on-gr id  record  contains  several  counters,  each  associated 
with  a  range  (user  definable).  A  counter  is  incremented  for  any  event 
occurrence  having  a  measurement  value  falling  in  its  given  range. 

Fo  rraa  t: 


1  -d  ini e n s  io n- g r  id  =  record 
id  nun  b  e  r  :  i  n  teg  e  r ; 
length  :  integer; 

log  t: cue  :  integer; 
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size  :  integer; 

rangeid  :  integer; 

range  : array [0. . s ize-1 ]  of  Integer; 

1-grid  :array[0..1,  O.-size]  of  integer; 

cum  tot  :  array  [0..1]  of  integer; 

start  time  :array[0..1]  of  integer; 
end; 


Expiana  tion: 

idnumber  -  Event  identifier. 

length  -  The  record  length  in  words. 

log  time  -  The  time  the  record  was  last  logged  to  secondary  storage 
and  reinitialized. 

size  -  The  number  of  counters  in  the  record. 

rangeid  ■*  Identifying  number  for  the  interpretation  of  the  range. 

range  -  Array  containing  the  boundary  limits  associated  with  die 
coun  ters . 

1-grid  -  An  array  of  counters.  The  first  subscript  refers  to  the 
process  type.  For  example,  l-grid[0,4]  counts,  for 
processes  with  type  0,  the  event  occurrences  having 
measurement  values  specified  by  the  range  boundaries  given 
in  range[3]  and  range[4j. 

cum  tot  -  cum  to  t[  i]  holds  the  cumulative  total  of  the  measurement 
values  associated  with  processes  of  type  i  for  i  =  0  or  1. 

starttime  -  starttime[i]  holds  the  last  time  VIP  accessed  the 
record  of  a  type  i  process. 


Exampl  e: 

A  1-dimension-grid  record  might  be  used  to  record  information 
ultimately  used  to  compute  the  average  and  distribution  or  CPU  burst 
times.  The  rangeid  would  specify  that  the  range  values  correspond  to 


CPU  burst  times.  The  array  range  m  igh  t  -contain: 

r  ang  e  =  [  3  5  7  9  ...  ] 

VIP  accesses  the  record  upon  each  CP!'  r  on  te>:  t  switch.  The  CPU 
burst  time  is  calculated  by  subtracting  start  time  from  the  current  time. 
Suppose  batch  processes  have  been  singled  out  for  special  monitoring 
(i.e.  ,  type  1).  For  a  batch  process  having  a  measured  burst  time  of  8 
ms,  the  number  8  is  added  to  cumtot[l]  (1  for  a  batch  process  Type),  and 
1-grid [1,3]  is  incremented  by  one  since  range[2]  <  8  <_  range[3].  The 
average  batch  process  burst  time  can  later  be  calculated  by  the  DRP  by 
dividing  cum  to  t[  1  ]  by  the  total  count  which  is  found  by  summing 
l-grid[l,k]  for  k.  =  0..size. 

2.3.3  2-Dime  ns  ion-Gr  id 

A  2-dimension-grid  record  .is  an  extension  of  a  1-d  imens  ion-;:  r  id 
record  used  for  capturing  information  needed  to  determine  distributions 
where  the  distribution  depends  upon  some  network,  parameter.  The  record 
contains  several  counters.  When  an  event  occurs  the  specific  counter 
which  is  updated  depends  upon:  1)  the  process  type  associated  with  the 
event  and  2)  the  values  of  the  two  parameters  specified  by  range  id  (user 
def in able) . 

Forma  t: 

2-d  ime  ns  ion-grid  -  record 
idnumber  :  integer; 

length  :  integer; 

log  time  '.integer; 

size  :array[0..1]  of  integer; 

range. id  :array[G..l]  of  integer; 

rangeO  : array [ 0. . s ize[0] -1 ]  ci  integer; 
rangel  :  array  [  0.  .  s  ize  [  1  ]-l  ]  of  integer; 

2-grid  :array[0..1,  0..size[0],  0..size[lj]  of  integer; 
cum  tot  :array[0..1,  0..size[0]]  of  integer; 
start  time  :  array  [w..ij  of  integer; 
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Explanation: 


id  number  -  Event  identifier. 

length  -  The  record  length  in  words. 

log  time  -  The  time  the  record  was  last  logged  to  secondary  storage 
and  reinitialized. 

size  -  Array  containing  the  number  of  counters  in  the  record  in 
each  dimension. 

range  id  —  Array  containing  identifying  numbers  for  the 

interpretation  of  the  range  in  each  dimension. 

rangeO  and  rangel  -  Arrays  containing  the  boundary  limits 

associated  with  the  counters  in  each  dimension. 

2~grid  -  An  array  of  counters.  The  first  subscript  refers  to  the 
process  type.  The  remaining  subscripts  refer  to 

respective  range  id  interpretations.  For  example, 

2-gr id [  i,  j  ,k]  counts,  for  processes  of  type  .i,  the  event 
occurences  having  measurement  values  specified  by:  1)  the 
range  boundaries  given  in  rangeO  [j-i]  and  range0[jj  for 
the  first  dimension,  and  2)  the  range  boundaries  given  in 
rangel  [k~l  ]  and  rangel  [k]  for  die  second  dimension. 

cum  to  t  -  Array  of  cumulative  totals.  The  first  subscript  refers  to 
the  process  type.  The  second  subscript  refers  to  the 
first  dimension  range.  For  example,  cum  to  t[  t,  j  ]  holds  the 
cumulative  total  of  measurement  values  associated  with 
processes  of  type  .i  whose  first  dimension  interpretation 
is  bounded  by  rangeO[j~l]  and  rangeO[j]. 

start  time  -  s  tar  ttime[  i]  holds  the  last  time  VIP  accessed  the 
record  of  a  type  t  process. 


i 


A 
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Example: 

Suppose  the  in terarr ival  time  distribution  of  requests  to  the 
swapping  disk  is  desired.  However,  it  might  be  suspected  that  the 
distribution  depends  upon  the  number  of  processes  resident  in  main 
memory.  A  2-d  linens ion-gr id  record  could  be  used  as  follows. 

size  =  [3  4] 

range.id[0]  =  “number  of  processes  in  main  memory" 
rangeid[l]  *  "  inter arr ival  times  to  the  swapping  disk" 
r  ang  eO  *  [  3  6  9  ] 

rang el  =  [3  10  15  20] 

Suppose  a  type  0  process  makes  a  request  for  the  disk  and  this 
2-d imens  ion-gr  id  record  is  accessed .  The  value  of  s  tar  t  t.lme[ 0;  in  t:ie 
record  is  sub  trac  ted  from  the  current  time  and  this  difference  is  taken 
as  the  measurement  value.  The  value  of  starttime[0]  is  updated  to  the 
current  time  for  the  next  access.  Suppose  that  a  measurement  value  of 
22  msec  is  observed.  Suppose  that  the  number  of  processes  in  main 
memory  is  8.  The  counter,  2~gr  id  [0 , 2 , 4]  ,  would  be  incremented,  since  0 
is  the  process  type;  range0[i]  <  8  <_  rsnge0[2];  and,  rangel[4j  <  22. 
The  measurement  value,  22,  would  be  added  to  cumtot[0,2],  since  0  is  the 
process  type  and  rangeOfl}  <  8  _<  range0[2]. 

The  average  in  terarr  ival  time  of  type  i  processes  to  the  swapping 
disk  when  k  processes  are  resident  in  main  memory  can  be  calculated  by 
the  data  reduction  program.  This  average  time  is  found  by  dividing 
cumtot[Q,x]  by  the  sum  of  2-gr  id  [0  ,x  ,y  ]  ,  where  rangeOlx-1]  <  k  _< 
range0[x] ,  and  y  =  0,1, 2, 3, 4. 


2.  3. 4  Log 

A  log  record  is  specific  to  a  certain  event  and  .is  created  by  VIP 


and  then  saved. 


i 


Forma  t: 


Type  log  =  record 


id  nun)  be  r  :  .in  teg  e r ; 
length  :  integer; 
log  time  :  integer; 
proc  type  .‘integer; 
rest  :  other  info; 
end; 


Expl  ana  tion: 


id  number  -  Event  identifier. 


length  The  record  length  in  words. 


log  time  -  The  time  the  record  was  logged  to  secondary  storage. 

proc  type  -  Holds  a  value  of  1  or  0  indicating  the  process  type  of 
the  process  causing  the  event. 

rest  -  (Whatever  event  specific  information  that  is  necessary). 


Exampl  e: 

A  log  record  might  be  used  to  gather  information  about  individual 
jobs  in  the  system.  The  record  would  contain  fields  for  the  creator  and 
creation  time  of  the  job. 


3.  Ins  trumen ta tion  En titles 

This  section  details  the  .individual  items  to  be  measured.  The 
type  of  data  structure  format  used  to  record  the  information  (described 
in  detail  in  the  previous  section)  is  given  for  each  item.  Certain 
measurements  can  be  derived  from  o  ther  more  basic  measurements  (e.g., 
utilization  =  active  time/ total  time).  These  items  3re  to  be  obtained 
from  the  data  reduction  program ,  DI\P ,  and  are  so  indicated. 

The  individual  items  are  classified  into:  a)  I/O  devices,  b)  I/O 
controllers,  c)  terminal  interfaces,  d)  bus  resources,  e)  CPU  resources. 


f)  memory  resources,  and  g)  software  resources. 


item 


da ta  s  true  ture 


a)  I/O  devices  (e.g.,  RP06  disks,  TE16  tapes,  DR  11  parallel  interlaces 


1)  number  of  words  transferred  in  and  out 

2)  number  of  calls  ( i.  e.  ,  transfers,  transactions) 

3)  throughput  (  i.  e.  ,  calls  per  unit  time) 

4)  busy  (i.e.  ,  active)  time 

5)  utilization 

6)  seek  time 

7)  rotational  latency  time 

8)  transfer  time 

9)  queue  length 

10)  response  time  per  request  (i.e.,  queue  time  + 

service  time) 

11)  blocked  (i.e.,  device  idle  but  queue  is  nonempty) 

12)  in  ter  arrival  time 

13)  interdeparture  time 


l-gr  id 

DRP 

DRP 


0-gr  id 
DRP 

1-gr  id 
l-grid 
l'grid 
1-grid 


2-g  r  id 
2-grid 
2-grid 
2-g  r  id 


b)  I/O  controllers  (i.e.,  when  more  than  1  device  has  a  common 
controller) 


1)  number  of  words  transferred 

2)  number  of  calls 

3)  throughput 

4)  busy  time 

5)  utilization 

6)  queue  length 

7)  response  time 

8)  controller  free  while  device  busy 

9)  controller  busy  while  device  free 

10)  device  overlap 

11)  blocked  (i.e.,  controller  idle  but  queue  is  nonempty) 

12)  in  ter  arrival  time 

13)  in  terdepar  ture  time 


DRP 

DRP 

DRP 

0-gr  id 
DRP 


1- gr  id 

2- g  r id 
0-gr  id 
0-gr  Id 
2-grid 
2-gr  id 
2-grid 
2-g  r  id 


c)  terminal  interfaces  (e.g.,  DZ11  multiplexors) 


1)  number  of  words  transferred 

2)  number  of  calls  (i.e.,  process  wakeups) 

3)  throughput 

4)  busy  time 

5)  utilization 

6)  queue  length 

7)  think  time  from  terminals 

8)  response  time  from  system 

9)  number  of  active  terminals 

10)  blocked 

11)  in  ter  arrival  time 

12)  in  terdepar  ture  time 


1-grid 

DR? 

DRP 

0-gr  id 
DRP 

1-gr  id 
1-grid 

1- gr. id 

2- gr  id 

2-grid 

2-gr  .id 


d)  bus  resources  (e.g.. 


UNIBUS,  MASSBUS,  SBI,  console) 


1)  number  of  words  transferred 

2)  number  of  calls 

3)  throughput 

4)  busy  time 

5)  utilization 

6)  queue  length 

7)  response  time 

8)  bus  free  while  mit  busy 

9)  bus  busy  while  unit  free 

10)  blocked 

11)  interarrival  time 

12)  interdeparture  time 


i  -g  r  id 

C'RP 

DR? 


0-gr  id 
DR? 


e)  CPU  resources  (by  processor  mode) 


1)  burst  time  distribution 

2)  number  of  bursts 

3)  throughput 

4)  utilization 
3)  queue  length 

6)  response  time 

7)  number  of  interrupts  (by  type) 

8)  overhead  burst  time  distribution 

9)  overhead  number  of  burs  ts 

10)  overhead  utilization 

11)  monitor  overhead  time 

12)  monitor  overhead  utilization 

13)  blocked 

14)  in  ter  arrival  time 

15)  interdeparture  time 


1  r  id 
DR? 

D„? 

DR? 


^-gr  id 

1- gr  id 
DRP 
DRP 

0-g  r  id 
DRP 

2- g  r  id 
2-gr  id 
2^gr  id 


f)  memory  resources 


1)  multiprogramming  level  (i.e.,  number  of  active  PCHs ) 

2)  amount  of  utilized  core 

3)  amount  of  available  core 

4)  active  time  of  memory  box  0 

5)  active  time  of  memory  box  1 

6)  active  time  of  both  memory  boxes  simultaneously 

7)  utilization  of  memory  box  0 

8)  utilization  of  memory  box  1 

9)  utilization  of  both  memory  boxes  simultaneously 

10)  working  set  size 

11)  free  page  list  size 

12)  page  pool  size 

13)  number  of  dirty  pages  (  i.  e.  ,  modify  list  size) 

14)  number  of  page  faults 

15)  program  size 

16)  page  cache  hit  ratio 

17)  swap  size  distribution 

18)  number  of  swaps 

19)  percentage  of  program  residency 

20)  page  lifetime 

21)  number  of  page  reads 

22)  number  of  page  writes 

23)  in  ter  arrival  time 

24)  .interdeparture  time 


0-g  r  id 
0-g r ia 
0-gr  id 
DRP 


DRP 

DRP 


1  -g  r  id 
i-gr  id 
l^gr  id 
0-gr  id 
0-gr  id 
1-grid 
0-gr  id 


1-gr  id 
DRP 


1-gr  id 

1- gr  id 
0-g  r  id 
C-grid 

2- gr  id 
2-gr  in 


g)  software  resources  (i.e.,  any  queue  for  software)  (e.c 
schedulers,  I/O  files,  loaders,  exception  handlers,  01 


.  ,  alloca  tors  , 
serv ices ) 


l2< 

V 

l\ 

5) 

6) 
l) 

?! 


number  of  calls 
throughpu  t 
busy  time 
u  til  iza  tion 
queue  length 
response  time 
blocked  (  i.  e.  ,  queue 
is  idle) 
in  ter  arrival  time 
interdeparture  time 


nonempty  but  software  resource 


0~gr  id 
DRP 

0-grid 

DR? 

1  “g  r  id 
2-g  r  id 

2~gr  id 

9~gr^ 
2-gr  id 


4.  Summary 

A  design  of  a  software  instrumentation  package  has  been  described. 
The  target  machine  initially  is  a  VAX  11/780.  However,  the  design  is 
applicable  to  pag  ing/swapp  ing  systems  in  general.  A  data  structure  for 
the  collection  of  information  is  given,  and  the  information  to  collect 
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